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[57] ABSTRACT 

A licensing system provides enhanced flexibility for licens- 
' ing applications in a network. The licensing system includes 
a directory services database which stores all license infor- 
mation. The directory services database is accessed by 
providing a request to a license service provider associated 
with a server. The license service provider generates an 
executable entity based on the request parameters, which 
searches the database and, if the appropriate units are 
available, assembles a license. The license and the applica- 
tion are then transmitted to the requesting client. All aspects 
of the transaction are also stored in a database organized 
according to a transaction's relation to a particular license. 

22 Claims, 5 Drawing Sheets 
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FAULT TOLERANT ELECTRONIC 
LICENSING SYSTEM 

CROSS-REFERENCES TO RELATED 
APPUCAnONS 

This is a continuation-in-part of U.S. patent application 
No. 08/620,319, filed Mar. 15, 1996, now U.S. Pat. No. 
5,758,069. 

BACKGROUND OF THE INVENTION 

1, Field of the Invention 

The invention relates to licensing software, and more 
particularly, to licensing software electronically in a network 
envirorunent. 

2. Description of the Related Art 

Most software vendors cxirrently favor licensing as the 
preferred method of distributing software. Licensing soft- 
ware provides the vendor with a certain amount of control 
which may be used to the vendor's advantage. For example, 
Ucensing software allows the vendor to prohibit unautho- 
rized usage of the software that might facilitate unauthorized 
copying. In addition, licensing provides an advantageous 
method of providing and billing for software. Through 
licensing, the vendor may sell several identical copies of the 
same software and charge the buyer for each copy. 

Licensing schemes have been adapted for the network 
environment as weU as the individual personal computer. In 
a network environment, such as a client-server network, 
multiple users may access the same copy of a particular 
application. Consequently, the vendor can charge the net- 
work owner not for the number of copies installed on the 
network, but for the mmiber of users having access to the 
software. 

Software is conventionally licensed using an agreement 
between the vendor and the user or administrator. The 
agreement is typically either a conventionally signed con- 
tract or a "shrink wrap*' agreement attached to the packaging 
for the software, to which the hcensce acknowledges agree- 
ment by opening the package. 

Although traditional and shrink wrap licensing are more 
or less applicable to individual systems, they are not well- 
suited to the network environment. Both traditional and 
shrink wrap licensing schemes are difficult to enforce on a 
network where several users have access to the software. 
Consequently, various electronic systems have been devised 
for controlling access to software on a network. 

Electronic Ucensing typically comprises providing a set of 
criteria under which a request for an application from the 
server should be granted. One common licensing system 
uses a fixed set of licenses controlled by a license server. The 
Ucense information is maintained in a license database, 
along with information regarding which applications are in 
use and how many imits are stiU available. The information 
in the database may be encrypted to prevent forgeries. When 
an application is desired, the application commences run- 
ning. Code embedded in the application initially requests a 
license from the server to facilitate the execution of the 
application. The server checks the database of licenses, and 
if the appropriate licenses are available, grants the request. 
As requests are received and Ucenses granted, the relevant 
information is logged into a file to track usage of the various 
applications. 

If a license is not available, the client contacts another 
server to find the appropriate license. The client in the 
conventional system has the re^onsibility to obtain hcenses 



35,860 

2 

from the various servers, and the individual servers provide 
resources at the client's request. To facilitate such Ucensing, 
the apphcation typically includes a library of programs 
designed to contact the server, request a license, and track 
5 the resulting Ucense. 

Although such a licensing system provides some security 
against unauthorized usage of applications, it suffers several 
drawbacks. For example, the number of programs required 
for the client to request and maintain Ucenses occupies a 
^0 significant portion of the cUent's Umited memory resources. 
Further, a conventional licensing system stores most of the 
licensing information in the client's memory. Consequently, 
in the event of a cUent crash, the Ucensing information is lost 
and difficult to reconstruct. 

Conventional Ucensing systems also suffer limited scal- 
abiUty. When a call is made to a server, all of the execution 
occurs on each individual server for any parUcular caU. 
Similarly, if a license is located on a particular machine, all 
execution necessary to operate on that Ucense occurs on that 
machine. Consequently, a central server containing most of 
the Ucenses available on a particular network may be 
overworked while other, more local server resources remain 
idle. Similarly, if any particular server crashes or otherwise 
becomes unavailable, none of the Ucensing information 
^ associated with that server can be accessed by clients, even 
if other servers are operating. 

In addition, conventional hcensing systems rely on code 
embedded in the appUcation to establish the Ucensing 
attributes. Code is placed in the appUcation which interprets 
information received from the server to establish Ucensing 
parameters. Because the behavior of the Ucense is not 
estabUshed until after the request has been made and the 
Ucense obtained, the user cannot read the Ucense terms prior 
to the request. Moreover, this system lacks flexibility. To 
change the licensing terms, the code in the application must 
be revised. 

An electronic software Ucensing system is thus needed 
which overcomes the shortcomings of the prior art, 

SUMMARY OF THE INVENTION 

An electronic licensing system according to various 
aspects of the present invention provides alternative meth- 
ods and apparatus for licensing software in a network 

45 environment. License information is suitably stored in a 
distributed database among several servers. In the preferred 
embodiment, the license information is stored and accessed 
in conjunction with a directory service, such as Novell 
Directory Services (NDS). The license information may be 

50 coupled with any suitable attributes to create a desired 
Ucensing poUcy. Clients are equipped with a suitable Ubrary 
of application programming interfaces (APIs) for acquiring 
and managing licenses. To request an application, the cUent 
assembles a request having the desired Ucense criteria, such 

55 as the pubUsher, product, version, and number of license 
units. This information is provided with other relevant 
information, such as the user's name. 

When the request for a Ucense to an appUcation is 
received by a local server, the server xises the directory 

60 service to locate license information which satisfies the 
request criteria. If the requested license information is 
available to the requesting cUent, a Ucense service provider 
(LSP) constructs a license certificate object and coUects that 
information into the license certificate object. If the license 

65 units are available to grant the request, the information in the 
directory services database is then adjusted to reflect the 
granting of the Ucense. The directory services system then 
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suitably replicates the data according to a corresponding tolerant licensing apparatus and method for licensing soft- 
partitioning and replicating scheme to maintain the integrity ware in a network. Referring now to FIGS. lA and IB, a 
of the licensing information. licensing system 100 according to various aspects of the 

In a system according to a preferred embodiment of the Present inveation suitably includes a network 102 compris- 

present invention, most of the license transactions occur at 5 ing a pluraHty of servers 104, at least one cHcnt 106, and a 

the servers; the client merely bundles the arguments for a communicaUons system (e.g., a network bus) 108. Each 

license request and transmits them to the server. server 104 suitably comprises a high-speed computer oper- 

^ »t *u 1- * • J f *u 1* atmg on a network operatme system, such as a Novell 

Consequently, the client resources reqmred for the license vt^t • ^ -.i 

system are relatively smaU. NetWare server operaUng system Any suitable operating 

», ^, in system, however, may be utilized m accordance with the 

In accordance with a farther aspect of the present present invention 

invention, recoverability of the system is enhanced. To r™ ^ , Vn-i • li ^ ^ c j- ^ u . j 

. ' , / . 1 J . . The network 102 is suitably configured for distributed 

anticipate a client crasn, the chent only needs to store a . j j -i- . 

Mc.nl handle associated with the Uc^ose request. TTie processing and to ac»mmodate a directory semces system. 

... J ^- * . J • J ?u J In a preferred embodiment, the directory services system 

remaming information is stored iq the server database, and , . - ' j* * u /j * ^ ji- 

u ^ ui- u J u c J- *u 1 * 15 comprises a multiple-platform, distributed network direc- 

may be reestablished by findmg the particular transaction . ^ . r i Krrx\n^TT rMncr^r^nv ct-n 

• * J -.u *u V t, Ji • *L xTT^c J * u tory service, for example NOVELL DIRECTORY SER- 

associated with the hcense handle m the NDS database. t^;-,t-otm /i!jt^c<tia\ w u i l i 

- ^. I • , _j- * . f VICES™ (NDS™) 103, which provides global access to 

Further, a licensme system accordmg to vanous aspects of , , ^ ' ' r l .t. j 

^, ' . ^- ■ I. - . 1 r I. r 1 ^ • ^ r network resources regardless of where the resources reside, 

the present invention 15 highly fault tolerant m the event of vrrxo ^A1 • i j i l i * j • r 

i_ T» ^Y. /■ . . * NDS 103 includes a global, distnbuted mformation system 

a server crash. Because the directory services system auto- ^ • * • • r ^* l * - ^ j 

^•1, 1- * 1- • • c • 9/1 that mamtains mformation about every resource associated 

matically rephcates licensmg mformation among vanous ^ ^ , • i • . ^ 

\. . c • . J with a network, including tisers, groups, pnnters, volumes, 

servers, license mtormation associated with a particular , , . r«_ . r 1- - r t t • I 

. . 1 , -1 ui *u J? *i T . J Mid other devices. The information is preferably organized 

server is not lost or unavailable if the server fails. Instead, „ r . • . ^ : ^- 

^, . f L ^ • J *u L- / as a collection of obiects, each obiect representing a par* 

the inlormation may be retrieved from another server which , . , , i- m .t_ i-i t r 

. „ . , 1* • * *• ticular device, module, application, file, or the like. Infor- 

has received a replica of the licensmg information. ^- i * *i_ • i. • j 

^ . . ^ . ^ , 25 mation relatmg to the vanous resources may be organized 

In accordance wiUi yet a further aspect of the present ,^ administrator in a hierarchical tree 

mvention. licensing flexibility is also enhanced. Tie hceiis- s,n,cture. For example, referring now to FIG. 4, a tree 

mg cntena may be adjusted by revising the contents of the ^^^j^^, ^e organized into a series of branches 402, 

NDS database and the client APIs Because the application s^b-branches 404, and so on, which may correspond to 

requires no particular code to facilitate licensmg, recompi- particular user groups, device types, geographical location, 

lation or re-linfang of the apphcaUon bmaries is unnecessary „^ ^^^^ ^^jjable classifications. Similarly, the sub-groups 

to change the licensing attributes. In addition, the structure ^ ^e organized by dividing and sub-dividing 

of the database and the APIs facilitates the use of unoon- ^sources into individual branches as may be convenient, 

ventional licensmg modes by applymg vanous different £^^.1, g^^^p^ sub-group, or the like is typically referred to as 

cntena to the license informatioti m Uie database and the ^ particular context, container, organizational unit, or the 

hcense request. Further, the distributed nature of the data- according to the particular configuration of the network 
base provides enhanced scalabiuty and allows several serv- 

ers to be searched with a single request from the client. x^nomi 'j l . rr. .• ■ ^ -.l 

^ ^ NDS 103 provides a host of functions in conjunction with 

BRIEF DESCRIPTION OF THE DRAWING a licensing system according to various aspects of the 

HGURES 40 present invention, including, for example, organization. 

The subject matter of the invention is particularly pointed ^'^ '^P'j^^^" °[ ^"""''^ components. NDS 103 

out and distincUy claimed in the concluding portion of the ^"^f ^^,}° ^ a logical mamier 

specification. The invention, however, both as to organiza- admimstraUon, apphcaUons shanng, document shanng, 

tion and method of operation, may best be understood by f"^ l*^' "Krectory service organaation may further 

reference to the foUowing description taken in conjunction « *° ^^'^ kcdiUl. seatchmg for hcense infor- 

with the claims and the accompanying drawing, in which: de'^'jjelov?'^ "^"""^ ^ descnbed in greater 

nOS. lA-B are a block diagrams of a network according , , ' , ,. , ,. 

,„ „„ ■ , „c In the present embodiment, the directory services system 

to vanous aspects or the present mvention , -r, v.^^ 

... - suitably includes a distnbuted database 112. The NDS 

FIG. 2 IS a block diagram of the L^P of FIG. 1; ^^^^^ ^ configured to automatically repHcate infor- 

FIG. 3 is a diagram of the organization of a hcense record nation in the NDS database 112 and store the replicated 

versions at alternative locations in the NDS database 112. 

FIG. 4 is a block diagram illustrating an example con- Replication of the information in the NDS daUbase 112, 

figuration of a network serviced by a directory service; including the hcense information, provides fault tolerant 

FIG. 5 is a flow diagram of a process for a cheat to locate 55 login, administration, and licensing services. More 

an LSP; particularly, the NDS database 112 is typically separated into 

FIG. 6 is a block diagram of a series of implementation multiple distributed sections, known as partitions, which are 

objects generated in response to requests; distributed across the network 102. NDS partitions are 

FIG. 7 is a flow diagram of a process for installing a rephcated and updated among various memory locations 

hcense in the license certificate database; and 60 within the network 102 according to prc-sclectcd procedures 

HGS. 8A-B comprise a flow diagram of a process for ^ necessary or desirable to provide 

requesting and generating a license for an apphcation. effective fault tolerance. The NDS system 103 automatically 

updates informatioD across the network 102 as data assod- 

DETAILED DESCRIPTION OF PREFERRED ,ted with a particular partition is modified. Thus, if a 

EXEMPLARY EMBODIMENTS primary partition is lost due to a server crash or other cause, 

A licensing system according to various aspects of the the NDS system 103 automatically reconfigures itself to use 

present invention provides a flexible, robust, and fault an alternate copy. It should be noted, however, that the 
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replication process of the NDS system 103 may be limited 
or controlled to optimize the efi&ciency of the licensing 
system. For example, servers that do not include an LSP or 
otherwise provide licensing services may not need to repli- 
cate license-related data. s 

In the present embodiment, at least one of the servers 104 
has access to the NDS database 112, which is suitably 
managed by NDS 103. In particular, NDS database 112 
stores all of the information relating to the various licenses 
available via the LSPs 110. The license information in the 10 
NDS database 112 is suitably organized into license record 
objects, each of which suitably contains a Ucense certificate 
supphed by a vendor or other installer along with additional 
informatioQ relating to, for example, the location of assign- 
ment information and user information. 

In the preferred embodiment, two extensions are used to 
provide infrastructure for creating and maintaining stored 
license record objects, a product schema extension and a 
certificate schema extension. The product schema extension 
provides a reference mechanism for locating Ucense record ^ 
objects, and suitably corresponds a series of attributes, for 
example corresponding to the publisher, product, and ver- 
sion of a Hcensed application. The product schema extension 
may be located within a particular organization or organi- 
zational unit in the NDS system 103 to organize similar or 
related license record objects in the organization or organi- 
zational unit. 

The certificate schema extension corresponds to indi- 
vidual stored license record objects. An instance of a license 
record object subject to a certificate schema extension only 
exists witlain product container subject to a product schema 
extension. All of the Ucense record objects associated with 
a particular application version and located in an organiza- 
tional unit, for example, are suitably associated with a single 
product container. Associating various license record objects 
with product containers facilitates searching for Ucense units 
without examining every object in the organizational unit. 

The license certificate is stored in the Ucense record object 
in a block copy fashion, so that aU of the data and structure 
of the certificate are preserved. The license information 
stored in directory services database 112 is suitably stored in 
a format common to each license record object. Additional 
memory space is also suitably provided for information 
required by licensing system 100. For example, memory 
space may be provided for entry of information relating to 
the user, Ucense handle, number of Ucense units consumed, 
the last time of update, assignment, and owner. Each license 
record object is suitably extendable by adding additional 
identifiers that may be recognized by executable license 
certificate objects. 

Referring now to FIG. 3, a suitable format for a license 
record object 302 comprises an identifier field 304, a data 
length field 306, and a data field 308. A suitable identifier is 
stored in identifier field 304, for example to identify the 55 
nature of the Ucense record object 302. Data length field 306 
describes the length of data field 308, suitably in bytes. Data 
length field 306 suitably comprises a four byte number, for 
example in Uttle endian fonoaat. Data length field 306 may be 
read to determine where the current license record object 
302 ends and where the next Ucense record object 302 
begins. 

Data field 308 suitably contains information specific to 
the Ucense. Data field 308 is formatted in any suitable 
manner to be compatible with licensing system 100. In 65 
particular, data field 308 suitably contains nested sets of 
identifiers, data length fields, and data fields for various 



characteristics and variables associated with the license 
record object. For example, each entry in the data field 
suitably includes an identifier 304A--C which indicates the 
type of information in the entry, e.g. an error attribute, 
ownership data, etc. A data length field 306 A-B indicates 
the length of the entry, and a data field 308A-B includes the 
actual information. The format may suitably be determined 
according to a portion of the identifier, so that if Ucensing 
system 100 does not recognize the relevant portion of 
identifier field 304, data field 308 is ignored. The informa- 
tion stored in data field 308 is provided by license instaUa- 
tion or creation, as described ftirther below. 

The data fields 308 smtably include both static and 
dynamic portions. The static portions arc set once when the 
Ucense record object is instaUed on the directory services 
database 112 and remain unchanged for the duration of the 
Ucense. The dynamic portion may be changed as the license 
certificate is utiUzed and thus manipulated. 

In the preferred embodiment, the dynamic and static 
portions are suitably stored in a single multi-valued 
attribute. The static portion includes the actual license 
certificate binary in its original form. Storage of the original 
binary fadUtates authentication mechanisms employed by 
the licensing system and/or the associated application. 
Because information is typically only added to the record to 
describe units in use, i.e. in the dynamic portion, unautho- 
rized manipulation of the Ucense certificate is inhibited. The 
dynamic portion of the Ucense record object stores infor- 
mation relating to its current state, which aUows the object 
to be modified and transmit the modifications to the next 
process using the Ucense record object. This aUows certain 
values in the object to be manipulated without affecting the 
other values. 

At least one server 104, and preferably multiple servers 
104, further includes an LSP 110 for performing license 
U-ansactions. LSP 110 performs several licensing functions, 
for example receiving requests from cUents 106 and main- 
taining and searching the NDS database 112. LSP 110 is 
implemented in any suitable manner, for example in 
software, suitably comprising a NetWare Loadable Module 
in the operating system. 

Referring now to FIG. 2, LSP 110 suitably comprises a 
NetWare Core Protocol (NCP) Extension Entry Point code, 
which is referred to as the NCP handler 202; a server stubs 
module 204; an engine code 206; and a plurality of imple- 
mentation objects 208, which may be generated, stored, and 
destroyed as necessary by the LSP 110 to fulfill its functions. 
The NCP handler 202 receives messages fi"om clients relat- 
ing to various licensing functions. To handle multiple 
messages, the NCP handler 202 suitably processes several 
requests concurrentiy. NCP handler 202 notes the message 
contents, as well as the source of the message to establish a 
return location. To initiate fulfiUment of the request, the NCP 
handler 202 transfers control of the request to the server 
stubs module 204 or to a queue to await processing. 

The request is sent to the server stubs module 204 with the 
request information and the client information received from 
the cUent 106. The server stubs module 204 dissects the 
information received from the NCP handler 202, initiaUy 
determines which particular function is requested, and con- 
verts the message into an appropriate format for the other 
components of the server 104. Based on the type of 
transaction, the server stubs module 204 then parses out the 
appropriate argxuncnts firom the message and transfers the 
restilts to the engine code 206. 

The server stubs module 204 may perform different tasks 
according to the type of request received. For example, the 
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server stubs module 204 suitably includes at least two NLSAPI. For example, the license certificate object 906 

sections for parsing client requests in the present embodi- facilitates adding assignment information to license record 

ment. A first section parses fimctions in the LSAPI, which is objects to assign or remove access rights for particular users 

submitted by the client 106 for requesting licenses. A second to an application. In addition, assignment of the license may 
section parses fimclions located in the NLSAPI, which is 5 be transferred to another \iser or group tising the license 

suitably submitted for managing licenses. certificate object 906. 

When the engine code 206 receives the results from the The license certificate object 906 also suitably provides 

server stubs module 204, the engine code 206 first checks all for removal of stale entries. 

arguments for validity, and if any arguments fail, returns a The license certificate object 906 monitors updates 
rejection message to the client 106. If the arguments are lo received from the various clients 106 to indicate that the 

valid, the engine code 206 translates the argimients from the apphcation is still in use. As described further below, if the 

particular functional request for licenses or information into update is not received within the appropriate update interval, 

an appropriate implementation object 208. In addition, the the license certificate object 906 terminates the license by 

engine code 206 translates results from an implementation performing a release operation. This configuration facilitates 
object 208 and returns the appropriate error codes or other ^5 modification of the license characteristics without affecting 

information to the chent 106. or modifying the API implementation code associated with 

The implementation objects 208 are suitably initiated by each client 106. 

the engine code 206 and create, locate, obtain, and manipu- The server 104 further suitably includes a transaction 

late license record objects in the NDS database 112. The database 105 for storing information relating to various 
implementation objects 208 may further include objects for ^ licensing transactions. The transaction database 105 suitably 

tracking license transactions and keeping records. For comprises a local database associated with a server 104, 

example, referring now to FIG. 6, the implementation unlike the NDS database 112. 

objects 208 suitably include a license handle object 902, a The LSP implements a transaction database object 210 

certificate database object 904, a license certificate object which operates as an interface with the transaction database 

906, and a transaction database object 908. i05 and tracks the usage history of a hcense handle object 

Upon receipt of a license request, for example an LSAPI, in the NDS database 112. Transaction database object 210 

the engine code 206 suitably generates a license handle suitably includes relevant usage information relating to the 

object 902. The license handle object 902 functions as an corresponding license handle object, such as v/hcn license 

object representation of the functionality of the request. units are consumed, v/hcn updates occur, when license units 

Further, the license handle object 902 assigns a unique are released, and error conditions. Transaction database 

identifier to the request for identification and record keeping objects 210 suitably organize information relating to 

purposes. licenses in transactional records based on each license 

The certificate database object 904 uses the information handle. For example, information relating to each transac- 

firom the engine code 206 to find license record objects affecting or based on a particular license handle is 

conforming to the request criteria. For example, the certifi- recorded in a transaction record devoted to that license 

cate database object 904 suitably receives a combination of handle. Consequently, unlike a chronological log, determin- 

publisher name, product name, version, and license handle. ing the usage history of a particular application does not 

After the certificate database object 904 has been created, it require a search of an entire database. In contrast, all of the 

may be used to search through license record objects in the relevant itrformation is stored in a record associated with an 

NDS database 112 or to retrieve specific license record identifying license handle. 

objects. The certificate database object 904 retrieves the Other useful implementation objects 208 may also be 

necessary information from the NDS database 112 and added to facilitate or simplify management and manipula- 

passes the binary state information to the constructor of the tion of the Hcense record objects in the NDS database 112, 
license certificate object 906. The certificate database object 45 such as a list object 910. A list object 910 may be used for 

904 provides access to the license record objects without generating and maintaining any type of list of items. For 

regard to the underlying certificates' policy attributes. example, a user may create a list object and then add items 

To access the NDS database 112 and perform various to the list to organize items in the NDS database 112. Users 

functions, LSP 110 suitably assembles a license certificate can then access items iteratively or search for a specific 
object 906 for any particular license record object installed 50 value within the list. Other useful, additional objects include 

in the NDS database 112. The license certificate object 906 a database object 912 for providing a simplistic abstraction 

provides for all of the basic manipulation of a single license of a database for very simple functionalities of a database, 

record object. A license certificate object 906 suitably com- Referring again to FIGS. lA-B, the client 106 suitably 

prises code for performing various functions within the NDS comprises a conventional network terminal, for example a 
database 112, such as adding, removing, requesting, and 55 personal computer or workstation. The cHent 106 is suitably 

releasing a license certificate. In addition, the license cer- connected to the server 104 through a conventional network 

tificate object 906 suitably provides information regarding interface. To operate in conjunction with the licensing 

the corresponding Ucense record object and its state. For system 100, the cUent 106 suitably includes a series of 

example, based on the user information or a license handle, application programming interfaces (APIs). The specific 

the certificate database object 904 suitably locates the cor- APIs provided may conform to the particular platform on 

responding license record object and constructs a license which the client 106 operates. 

certificate object, which transmits information relating to the The APIs are suitably provided to the cUent 106 by a 

current users, number ofunits in use, identifier information, client provider or library. The client provider, suitably 

default update period, ownership information, and the like to comprising a module loaded into each client 106 including 
the requesting client 106. 55 a combination of Ubraries and DLLs, provides the Hcensing 

The license certificate object 906 also suitably performs APIs and a remote procedure call (RPC) mechanism for the 

various hcense management functions in response to an cUent 106. The client 106 requests access to and manages 
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applications using the APIs. The RPC mechanism both communication components are preferably single sourced 

locates and communicates to LSPs 110. Finally, the client across all platforms to increase portability. For example, 

provider also suitably performs various h'brary maintenance NWCalls from Novell may be used, which provides a 

routines as may be necessary for the various shared hbrary platform independent mechanism for accessing Novell Net- 
formats. 5 Ware resources. 

The client 106 uses a series of functions gathered in the To communicate with the LSP 110, the client 106 first 

APIs furnished by the client provider to request hccnses locates an LSP 110, and then communicates its request to the 

from the LSP UO. The APIs are suitably linkable or addres- LSP 110. Each LSP connected to communications system 

sable entities according to the particular platform used by 108 suitably registers its handler 202. Consequently, when 

the client 106. The Hcensing API library associated with the client 106 seeks LSP 110, it suitably If scans its connections 

client 106 is suitably configured in a standard format, for for an NCP handler 202 registered with the appropriate 

example the industry standard called the LSAPI (vl.l), name. 

jointly created by Novell, Microsoft, HP/Gradient, and For example, refening to FIG. 5, to locate an available 

several other companies. Other API configurations may also LSP UO, the client 106 siutably scans its local connection 

be provided for different functions or to operate in conjunc- 15 1^^,]^ f^j- ^jj^ service name providing the Ucensing 

tion with different platforms. The APIs generally provide for service (step 500). If an LSP UO is located (step 502), client 

the acquisition and management of the licenses. The client 106 initiates its request, suitably using an appropriate RPC 

106 according to various aspects of the present invention (step 504). In a preferred configuration, a suitable transport 

suitably includes at least two h*brary sets. The first hbrary set mechanism comprises NCP extensions. If an LSP UO is not 
provides the license acquisition API, and the second is the 20 located, client 106 determines whether the directory services 

license management API. system is available (step 506). If the directory services 

The license acquisition API provides for obtaining, system is currently unavailable for some reason, an error 

maintaining, and releasing license units corresponding to a arises indicating that no LSP UO could be located (step 510). 

particular application. The hcense acquisition API prefer- If the directory services system is available, the current 
ably provides license acquisition functions compatible with ^ directory context is scanned for available LSPs 110 (step 

a broad array of platforms employed by licensing system 508). If no LSP UO is located in the current container (step 

100 platform so that software developers are afforded con- 512), chent 106 begins searching the parent container (step 

siderable flexibihty in designing applications which may be 514). The search continues through the parents of the current 

conventionally hcensed in the context of the licensing container until the root is reached (step 516). If no LSPs UO 

system 100. Preferably, the application requires very little arc found, the client 106 receives an enor indicating that the 

information about the licensing system's 100 particular licensing system 100 is not available (step 510). If an LSP 

process for acquiring and constructing Licenses, 110 is found, the client 106 connects to the located LSP UO 

The calls used to provide diis functionality suitably cor- and transmits its request and continues its commimications 

respond to industry standard APIs, such as the common (step 504). 

licensing API, or LSAPI, version 1.1, as described above. Each LSP 110 is suitably associated with various 
The standard API allows a server 104 to license applications attributes which indicate the status of the particular LSP UO. 
independent of the xmderlying licensing system 100. The For example, suitable attributes include transactional data- 
license acquisition API facilitates requesting, updating, and base attributes and an NCP pointer. The transactional data- 
releasing licenses, establishing the update period for base attribute may indicate whether the LSP UO is config- 
Ucenses, and translating error codes. ured to support a transactional database 105. The NCP 
The license managementAPI(NLSAPI) suitably provides pointer facilitates location of and communication with the 
access to information that directly pertains to the license corresponding NCP server object, 

acquisition process. In addition, the license management To facilitate licensing of the vario;is applications, the 
API also suitably provides for configuring and examining 45 license information relating to licensed applications is 

the Ucensing system 100. The license management API is installed in the NDS database U2, suitably in the form of a 

useful as an administrative tool and in a software manage- plurality of license record objects. The license information is 

ment system. The hcense management API fadUtates deter- suitably provided by the vendor to faciUtate access to 

mination of, for example, license usage, license restrictions, apphcations. The information stored in the NDS database 
license installation and information, and transactional jq 112 is suitably collectively available to each of LSPs UO via 

records. Further, the license management API suitably pro- NDS 103. Consequently, each LSP UO suitably has access 

vides calls for adding and removing license assignments to certain hcense information, depending on the LSP's 

from a license certificate, transferring ownership, and position in the hierarchical tree in the directory services 

installing a license certificate, for example into the NDS system and the privileges and limitations imposed upon the 
database 112. 55 individual LSP UO by the network administrator. 

Each respective client 106 communicates with the various The hcense system 100 according to various aspects of 

servers UO over communications system 108. The commu- the present invention allows various users to control entry 

nications system 108 suitably comprises a series of trans- and maintenance of hcenses other than the administrator, 

mission channels connecting servers 104 and clients 106, When a user enters a license into the hcense system 100, the 
including various supporting hardware and software. The go installer may be considered the "owner" of the license. Only 

commimications system 108 facilitates communications users having sufficient security clearance may modify or 

between two or more servers 104 and between servers 104 delete the installed license. Ownership of the license may 

and chents 106. The communications system 108 comprises also be transferred to other users. 

any suitable communications medium, such as conventional When a hcense is installed in the LSP UO, the adminis- 
copper wire, fiber optics, or wireless signals. ^5 trator may assign a Ucense to any NDS distinguished name. 

Client-server communications are suitably transport which may correspond to, for example, an individual, 

independent, for example using NCP extensions. Client machine, group, or container. If no assignment information 
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is provided, the application may be suitably treated as 
available to any client or user. The application correspond- 
ing to the License is then only available to a user with a 
proper security assignment. The assignments are suitably 
additive, such that multiple groups, machines, users, or 
containers may be assigned to a single license. Similarly, 
licensing system 100 provides for removal of particular 
assignments, suitably one assignment at a time. 

The information to support a license record object in the 
NDS database 112 is suitably created using a license cre- 
ation utility. The license creation utility also suitably facili- 
tates various policy control functions, such as modification 
of default installation parameters. The license creation util- 
ity allows the administrator to fit licensing system 100 to 
particular needs. 

For simplicity, the license creation utility suitably 
includes a series of default installation parameters. For 
example, the license creation utility may include one or 
more license creation templates. License creation templates 
describe detailed policies for license generation and behav- 
ior at the client 106. A scries of default templates may be 
provided for implementing various standard licensing mod- 
els. The license creation utility suitably prompts the installer, 
such as the administrator, for all information relating to the 
required entries, such as publisher, product, and version 
identifiers. In addition, the license creation utility may be 
adapted to request information suited to the particular net- 
work 102 or licensing system 100 configuration. For 
example, if security measures are desired, a number of secret 
codes, such as four, may be randomly selected and entered 
into the license information. These codes should be matched 
by the secret codes provided by the client 106 to gain access 
to an application. All of this information is stored in the 
license record object, which the installer maintains in con- 
fidentiality. 

Referring now to FIG. 7, upon receipt, license informa- 
tion is suitably stored as a collection of electronic license 
certificates, suitably in a common certificate binary format 
such as the format described above in conjunction with FIG. 
3. To install the license information in NDS database 112, 
the LSP 110 uses the license information received from the 
installer to create a license certificate object to access the 
NDS database 112 (step 700). The license certificate object 
suitably includes embedded code which parses the license 
information and creates an executable entity. The license 
certificate object then executes, causing the license certifi- 
cate object to be written into a buffer format recognized by 
the LSP 110 (step 702). The particular format may be varied 
to suit the particular NDS database 112 or licensing system 
100. LSP 110 then saves the formatted buffer into the NDS 
database 112, potentially containing many other license 
record objects, aU suitably in buffer form (step 704). The 
license certificate is then ready for retrieval. 

As described above, various policy attributes for a license 
are stored in data field 308 associated with a particular 
license record object. The data field 308 of each license 
record object 302 installed in NDS database 112 suitably 
stores a first group of information comprising required 
entries, and a second group of information comprising 
optional entries. The structure of the required entries is 
suitably common among each of the license certificates. The 
required entries describe the application's basic information. 
The optional entries, on the other hand, suitably provide 
system specific enhancements to the standard policy. 

The required entries suitably include fundamental infor- 
mation relating to the hcense record object. For example, the 
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required entries suitably include the publisher name, product 
name, version, and number of license units. The required 
entries also suitably include a unique identifier, such as a 
license or serial number, to distinguish the license record 

5 object from other licenses provided by the same publisher, 
product, and version. The required entries may also be 
configured to include various policy attributes to handle the 
consumption of license imits and error conditions. 
A set of policy attributes may be included in the optional 

jQ entries to describe various parameters of the license record 
object, for example the assigmnent information described 
above. The poMcy attributes stored in data field 308 facilitate 
the detailed and flexible description of the license terms and 
conditions, for example including a number of license units 

J 5 tag, a default units to consume tag, or a default metered tag. 
The descriptors may also be configured to provide various 
defauU license schemes, such as concurrent licensing, 
nodelocked, personal use, site restricted, and one-time use. 
Any suitable attributes may be included, for example: 

20 SHAREABLE: hcense units decremented on request, 
incremented on release. 
DEFAULT UNITS DESCRIPTOR: defines the default 

number of units to consume for one request. 
MINIMUM UNITS TO CONSUME: the minimum num- 

25 ber of units to consume from this given license object 
despite the number requested. 
It should be noted that the optional entries preferably do not 
provide more restrictive poficy than the required fields to 
eliminate incentive to install the license certificate on a less 

30 restrictive LSP. 

Similarly, other attributes that may be included relate to 
the behavior of the system in the event of a particular error 
condition, which are referred to as error handling attributes. 
Each error handling attribute suitably describes a reaction 

35 based on conditions encoimtered in the acquisition of license 
units. These actions may be provided with parameters to 
control the particular reaction. For example, for demonstra- 
tion purposes, an error handling attribute may aUow access 
to an apphcation even if insufficient units are available. 

40 Certain parameters may be installed to provide limited 
access, however, to limit the user's access to the apphcation. 

In a preferred configuration, a further attribute may be 
added to facihtate a nodal based licensing model for par- 
ticular apphcations. In a nodal based system, a single 

45 machine, node, or user consumes a single license unit for an 
application regardless of the number of connections between 
the client and the various other components or apphcations, 
i.e., the license record certificate is reusable for simultaneous 
connections to different servers. In the preferred 

50 embodiment, a "re-use" attribute may be added to the license 
record object which indicates that the license should be 
reused if the license record object is already utilized by a 
particular node, machine, or user. As a result, a single user, 
machine, or node consumes a single Ucense unit per utiU- 

55 zadon of the network, independent of the number of servers 
to which the user, machine, or node connects. 

In addition, the required entries suitably include security 
information, such as encrypted authentication information. 
An apphcation may be licensed with no security attributes at 

60 all. Alternatively, security attributes may be stored in data 
field 308, and different attributes may be provided to gen- 
crate different levels of security. For example, the vendor 
may use the common certificate security format, which 
utilizes certain "secrets" incorporated into the Hcense acqui- 

65 sition API to prevent unauthorized modification of the 
hcense certificate. The hcense acquisition API's secrets 
comprise a set of encrypted information, such as the license 
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informatioD plus an activation key, which are provided by a 
client to gain access to an application. In addition, an 
attribute may be added which requires the presence of a 
particular hardware security device, often referred to as a 
"dongle", to activate the application. Information relating to 5 
such security attributes may be included in data field 308. 

In a preferred configuration, a standard RSA public/ 
private key digital signature may be offered for higher end 
security. The static portion of the license record object is 
used to create a unique signature, which is also associated 10 
with the hcease record object. Consequently, by comparing 
the stored signature with an expected signature based on the 
static portion of the license record object, tampering with the 
license record object may be detected. 

The optional entries of data field 308 may further include 15 
informatioQ relating to particular licensing systems 100. For 
example, data field 308 suitably includes a system specific 
area tag. This tag may include a unique tag associated with 
a particular licensing system 100, along with any informa- 
tion pertinent to that licensing system 100. A license cer- 20 
tificate object encountering an unrecognized tag in this field 
may ignore the tag and continue processing the remainder of 
the information. All policy attributes are preferably additive 
so that they may be combined in any manner suited to the 
vendor or administrator to create an overall description of 25 
the application's behavior. 

After the Ucense certificates have been added to NDS 
database 112, the client 106 may request licenses for access 
to applications. Referring now to FIGS. 8A-B, when the 
user desires an application, the user suitably selects a name 30 
from a list or an icon, and then the application and the client 
106 automatically provide suitable information correspond- 
ing to any required fields (step 802). If all information is 
predetermined, no further information may be required. An 
output destination from which the request is made is also 35 
automatically inserted into the request. 

The chent 106 initially checks for a connection to a 
compatible licensing system 100 (step 804). If none is 
found, an error code is returned (step 806). If the licensing 
system 100 is available, the client 106 bundles the request 40 
arguments for the function, along with a function number, 
into a buffer, and uses the RPC mechanism furnished by the 
client provider to send the request to LSP 110 (step 808). The 
request is generated using the license acquisition API and 
smtably specifies particular information relating to the 45 
application, such as the publisher, product, and version for 
which license units are requested. In addition, the API 
suitably indicates the number of license units requested, so 
that the nimiber of units consumed is specified by the API. 
Client 106 transmits the request to LSP 110 and waits for a 50 
response. 

LSP 110 receives the request for a number of license units 
from the client 106 (step 810). The particular LSP 110 
receiving the request is suitably the nearest LSP, but may be 
any LSP in the network. The NCP handler 202 of LSP 110 55 
receives the request and transmits it to the server stubs 
module 204, The server stubs module 204 transmits the 
parsed request to the engine code 206, which decodes the 
request. 

After decoding the request, the engine code 206 generates 60 
a Ucense handle object 902 and a transaction database object 
908 (step 812). The License handle object includes a unique 
identifier associated with the transaction, which the trans- 
action database object 908 suitably copies and stores in the 
transaction database 105, along with other information asso- 65 
ciated with the license request. For example, the user's NDS 
distinguished name and the application pi±)lisher, product, 
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and version may be entered into the transaction database 105 
and associated with the license handle. Any calls made by 
the client 106 utifizing the particular license handle are then 
logged as action corresponding to that license handle in the 
transaction database object 908. An action corresponding to 
a license handle suitably records relevant information in the 
transaction database 105, such as what call was made, time 
of the call, number of units involved, and the outcome of the 
call. 

Engine code 206 then creates a certificate database object 
904 to search the NDS database 112 (step 814). Hie certifi- 
cate database object 904 searches the NDS database 112 for 
one or more license record objects relevant to the request, 
i.e., relating to the appropriate application (step 816). The 
certificate database object 904 accesses NDS database 112 
and searches through the appropriate objects in the tree to 
determine whether the necessary License record objects have 
been installed. If so, the certificate database object 904 
creates a license certificate object 906 using the information 
in the license record object 

The license certificate object 906 suitably determines 
whether the Kcense units corresponding to the license record 
object are available to the requesting client by reviewing, for 
example, the policy attributes of the license, the user infor- 
mation associated with the request, any existing license 
assignments, the number of units in use, and the raw number 
of units originally installed. 

If all of the available containers have been searched (step 
822) and the appropriate license record objects cannot be 
located, LSP 110 retimis an error message to client 106 (step 
824). If sufBcient license units are available among the 
license record objects, the license certificate objects 906 
consume the detected license \mits. To consimie the units, 
each license certificate object 906 checks the license infor- 
mation for any existing assignments. If an assignment exists 
in the license record object, it perforaas a security equiva- 
lency check to determine whether the requesting client 106 
is among those assigned to the license certificate (step 828). 
If no match is found, the Ucense certificate object 906 
returns an error to the requesting client (step 830). 

If a match is found, the license certificate object 906 
consumes the license units by updating the dynamic portion 
of the license record object with the user information, 
license handle, and how many units are to be consmned (step 
832). The relevant license record objects in the NDS data- 
base 112 are modified to indicate that the license units are in 
use. All such modifications of the Hcense record objects are 
performed according to the policy attributes associated with 
the license record object. It should be noted, however, that 
certain core information in the license record object remains 
imdisturbed, for example the nmnber of units associated 
with the license. The number of units consumed is separately 
noted in a different field, whereas the total number of units 
associated with the licerise record object cannot be changed 
by the license certificate object 906. 

The license unit acquisition process continues to search 
for hcense record objects untU aU of the required units are 
obtained or the necessary license record objects to proceed 
cannot be found. If insufficient license units were located 
(step 834), a detailed error code indicating the grounds for 
denial of the request is returned to cUent 106 and stored in 
the transactional database (step 836). If the appropriate 
hcense imits are located, however, the license certificate 
object 906 suitably grants the license based on the various 
policy attributes, A resulting status code and the license 
handle are suitably shipped to cliem 106 (step 838). When 
the client 106 receives a response, it removes the output 
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aiTguments from the output buffer, and sends the results back 
to the calling application. 

The client 106 suitably periodically updates the license 
handle object 902 within the specified update period. For 
example, the appropriate update period may be obtained by 
the application using a licensing function call. In response, 
LSP 110 suitably returns an appropriate update period, such 
as the shortest update period specified by any of the stored 
license certificates. Updating the license handle object 902 
suitably comprises a message sent to LSP 110 indicating 
continued use of the application. If the update fails to occur, 
LSP 110 treats the failure as a return of the license units. 
Consequently, the dynamic portion of the license record 
object is suitably modified to indicate that the license units 
are available for use by other clients, if appropriate, based on 
the particular licensing policy. The application then returns 
an error message to the client 106. The update requirement 
provides for abnormal termination of the appUcation and 
license, such as in the event of a system crash or power loss. 

When client 106 no longer requires the license units, the 
application transmits a release notification to LSP 110. 
When the release message is received by LSP 110, the 
license certificate object 906 marks each of the license 
certificates associated with the particular license handle as 
no longer in use. If the policy attributes permit, the license 
units may then be designated as available. NDS 103 then 
notes the release in the NDS database 112, and the transac- 
tion is complete. 

A licensing system 100 according to various aspects of the 
present invention may also be suitably configured to provide 
several software metering facilities. Software metering 
essentially comprises enabling an application using an inter- 
mediary application. Instead of the application directly 
requesting a Hcense fi-om the LSP 110, the request is placed 
by the intermediary application. The intermediary applica- 
tion monitors usage of executables, and when it detects the 
usage of a "metered" executable, it requests a license from 
LSP 110 on behalf of the executing application. The inter- 
mediary application first maps the executable name to a 
publisher, product, and version name, and then requests the 
licensing units from LSP 110 using the standard function 
calls. 

The intermediary application is suitably capable of 
requesting a fully enabled license certificate from licensing 
system 100. The security features, however, may be 
disabled, especially for a trusted environment; no security 
against forgery is typically required because the end user 
creates the license utilized by the intermediary application. 
In addition, the metering function typically allows unlimited 
access to the metered application. 

When the intermediary application accepts a request for 
an application, the intermediary application enters the infor- 
mation about the product into licensing system 100, This 
includes all of the information contained in a typical license 
certificate, including the number of units and any policy 
descriptions which help describe the license attributes. A 
licensing function call is used in the intermediary applica- 
tion which allows the software metering system to directly 
enter information into the NDS database 112. The function 
call suitably allows entry of all information relevant to the 
product, including the publisher, product, version, units, and 
policy attributes. Security information, however, is typically 
not facilitated through the intermediary application, which 
allows the metering information to be distinguished from 
information obtained by the installation of license certifi- 
cates created by a manufacturer. This also provides secmty 
against an end user directly entering information for a 
vendor licensed application which requires a vendor sup- 
plied license certificate. The metering utility is also suitably 
responsible for mapping an executable name to a publisher, 
product, and version. The software metering system is also 
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suitably responsible for gathering the information about 
application to be metered and for performing the call which 
translates that information into licensing system's 100 data- 
base. 

The software metering system configuration is particu- 
larly useful to determine the usage of individual applications 
in an enterprise network environment, which applications 
are installed on a network, and which users are using them. 
In addition, it is often desirable for licensing system 100 to 
inform the administrator of any error conditions which may 
have occurred during the execution of any relevant software. 
Tracking software usage is facilitated by the transaction 
database, which is suitably organized such that all actions 
performed by a single application in a particular execution 
session and utilizing a particular license handle are grouped 
together. A software asset management system may read 
entries from the transaction database through a set of func- 
tion calls. The database is suitably chronologically orga- 
nized based on the time at which the first action in a 
transaction occurred. Examples of actions to be recorded 
include the request for license units, granting of license 
units, updates, and release of license units. The individual 
entries in the transaction database may be assembled into the 
required usage information and presented to the user or 
administrator. Similarly, information regarding errors are 
also placed in the transaction database. Errors are suitably 
recorded in the transaction record of the application which 
generated the error condition. Every transaction entry, 
including requests and errors, suitably contains information 
about the user which generated the action. Consequently, the 
administrator may track which users are not appropriately 
authorized or are suffering multiple error conditions. 

An electronic licensing system according to various 
aspects of the present invention thus provides a distributed 
database among several servers. As a result, any given server 
is unlikely to be overloaded as a licensing server. In addition, 
license information may be coupled with any desired 
attributes to create a desired Licensing policy. Because the 
client merely bundles the arguments for a license request and 
transmits them to the server, client resources are preserved. 
In addition, recoverability of the system is enhanced. All 
pertinent information is stored in the NDS database. To 
reestablish the license application, the client only needs to 
store the license handle associated with the license request. 
Further, in the event of a crash of a server, the distributed 
database using the replicating directory service provides for 
a high degree of fault tolerance. 

While the principles of the invention have now been made 
clear in illustrative embodiments, there wiQ be immediately 
obvious to those skilled in the art many modifications of 
structure, arrangements, proportions, the elements, materials 
and components, used in the practice of the invention which 
are particularly adapted for a specific environment and 
operating requirements without departing from those prin- 
ciples. 

We claim: 

1. An electronic licensing system for providing access to 
a plurality of applications in a computer network 
environment, comprising: 

a distributed license database configured to store autho- 
rization parameters relating to \isage of the pluratity of 
applications, wherein information stored in said dis- 
tributed licensed database is replicated, each replica 
being stored on a separate computer; 

a license service provider configured to receive requests, 
search said distributed license database for authoriza- 
tion parameters corresponding to said received request, 
and facilitate access to the application only if the 
corresponding authorization parameters are stored in 
said distributed license database; and 
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a client configured to generate a request for access to one 
of said plurality of applications and transmit said 
request to said license service provider, wherein said 
request includes: 

a generic request structure for requesting access to any 

of said plurality of applications, and 
at least one identification parameter embedded in said 

generic structure corresponding to said requested 

application. 

2. The electronic licensing system of claim 1, wherein 
said client includes an API configured to generate said 
request. 

3. The electronic licensing system of claim 1, wherein 
said at least one identification parameter includes a publisher 
indicator, a product indicator, and a version indicator. 

4. The electronic licensing system of claim 1, wherein 
said license service provider is configured to generate a 
separate certificate database object for each request gener- 
ated by said client, wherein each certificate database object 
generated is configured to search said distributed license 
database for said authorization parameters, and wherein 
each certificate database object is an executable entity. 

5. The electronic licensing system of claim 1, wherein 
said authorization parameters arc stored in said license 
database according to a uniform format. 

6. The electronic licensing system of claim 1, further 
comprising a transaction database configured to store infor- 
mation relating to said request. 

7. The elecu-onic licensing system of claim 6, wherein 
said license service provider is configured to assign a unique 
identifier to said request and store said unique identifier in 
said transaction database. 

8. The electronic licensing system of claim 1, further 
comprising a transaction database configured to store infor- 
mation relating to said request. 

9. The electronic hcensing system of claim 8, wherein 
said license service provider is configured to assign a unique 
identifier to said request and store said unique identifier in 
said transaction database. 

10. An electronic licensing system for providing access to 
a plurality of applications in a computer network 
environment, comprising; 

a client configured to generate a plurality of requests, each 
request corresponding to at least one of the plurality of 
apphcations; 

a distributed license database configured to store autho- 
rization parameters relating to usage of the plurahty of 
apphcations, wherein said authorization parameters are 
stored on a plurality of computers; and 

a license service provider configured to receive said 
requests fi-om said client and generate a separate cer- 
tificate database object for each of said requests, 
wherein said certificate database object is an executable 
entity configured to search said hcense database for 
authorization parameters corresponding to the received 
request and facilitate access to the appUcation only if 
the corresponding authorization parameters are stored 
in said license database. 

11. The electronic licensing system of claim 10, wherein 
said client includes an API configured to generate said 
request. 

12. The electronic licensing system of claim 10, wherein 
said request includes a product indicator, a version indicator, 
and a source indicator corresponding to the requested apph- 
cation. 

13. The electronic licensing system of claim 10, wherein 
said authorization parameters are stored in said license 
database according to a uniform format. 

14. The electronic licensing system of claim 10, wherein 
said authorization parameters are automatically stored on at 
least two of said computers. 
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15. An electronic licensing system for providing access to 
a plurality of applications in a computer network 
environment, comprising: 

a client configured to generate a pluraHly of requests for 
^ at least one of a plurality of applications; 

a distributed license database configured to store autho- 
rization parameters relating to usage of the plurality of 
applications, wherein said authorization parameters are 
copied to multiple locations in said distributed license 
database; 

a certificate database object corresponding to each of said 
requests generated by said client, each certificate data- 
base object being configured to search said license 
15 database for matching authorization parameters corre- 
sponding to said client request, wherein said certificate 
database object is an executable entity; and 
a licensed certificate object generated by said certificate 
database object for each client request having matching 
20 authorization parameters. 

16. The electronic licensing system of claim 15, wherein 
said client includes an API configured to generate said 
request. 

17. The electronic licensing system of claim 15, wherein 
25 said request includes a product indicator, a version indicator, 

and a source indicator. 

18. The electronic licensing system of claim 15, wherein 
said authorization parameters are stored in said license 
database according to a uniform format. 

19. The electronic licensing system of claim 15, wherein 
said authorization parameters are automatically copied to 
multiple locations in said distributed license database. 

20. Amethod of providing access to software applications 
in a computer network environment, comprising the steps 
of: 

storing a plurality of authorization parameters relating to 
the applications in a license database distributed across 
a plurality of computers; 
requesting access to at least one of said apphcations; 
i;o generating a certificate database object in response to the 
requesting step, said certificate database object being 
operative for searching said license database for param- 
eters corresponding to said requested access; and 
when corresponding parameters are found by the certifi- 
45 cate database object, generating a licensed certificate 
object, said licensed certificate object being operative 
for determining whether to allow access to said appli- 
cation by reviewing license information associated 
with the requested application. 
50 21. The method of claim 20, wherein said step of storing 
said plurality of authorization parameters includes the steps 
of: 

creating a local license certificate database in each of said 

plurality of computers; 
writing authorization parameters associated with each of 

the applications into a buffer format; and 
storing said formatted authorization parameters into said 

local hcense certificate database. 
22. The method of claim 20, further comprising the steps 
of: 

assigning a license handle to said requested access; 
storing said hcense handle in a transaction database; and 
providing said Hcense handle to the source of said 
65 requested access. 

4i + * 4i « 
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